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Sir: 

This Reply is in support of the Appeal Brief filed on September 6, 2007 and concerns the 
propriety of the Examiner's final rejection mailed March 6, 2007 in connection with the above- 
identified patent application and Examiner's Answer mailed October 30, 2007. 

A. Response to Section 9 of the Answer 

This Reply separately addresses two points raised in the Examiner's Answer in 
connection with Franklin et al. ("Franklin," U.S. Patent No. 6,105,069). First, applicants 
respectfully disagree with the Examiner's statement on page 4 that Franklin discloses "a 
procedure that retrieves licensing information from . . . resources." Second, applicants disagree 
with the Examiner's statement that Franklin discloses embodiments wherein Franklin's invention 
or "product" is used "rather than for the direct execution of a software product." Further, this 
reply addresses the Examiner's silence with regard to a feature defined in applicants' claims. 
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Although Franklin is very broadly described in terms of its functionality, applicants 
submit that Franklin's system in its essence requires the Novell networking system ("Novell"). 
This is clearly indicated as a function of Franklin's NAL, which is well-known to be a functional 
component of Novell and a requirement for the distribution, operation and maintenance of 
application software and resources distributed over a Novell network. 

L Franklin Does Not Disclose Retrieving Licensing Information From A Resource. 

Respectfully, the Examiner's Answer relies on a mischaracterization of the teachings and 
scope of Franklin both with respect to particular passages cited the Examiner and to Franklin's 
complete disclosure, more generally. 

Franklin regards a licensing controller for network directory services ("NDS"). Any 

NDS (including Franklin's preferred Novell NDS) requires a database "schema" that stores 

information about software and hardware resources that are available to users over a network. 

Particularly, Franklin teaches use of a Network Application Launcher ("NAL") that, via the 

NDS, enables a user to install and/or run a software product. In particular, Franklin states, 

[t]he present invention's methods and apparatus for centrally managing 
application programs in a computer network, improve a Network 
Application Launcher (NAL) by modifying a database schema and 
executables (utilities) for managing its information. The database schema 
defines resources that can be represented, so network administrators have an 
efficient and effective way to make resources available on the network. 
Controlling organization, linking, rights assignments, and licensing or other 
access to a resource may be done simply, and transparently to network 
users, or groups of users, needing particular network resources. (Franklin, 
column 2, lines 16-28). 

In short, Franklin regards an improved NAL by "modifying" the NDS database schema, 
and includes "executables (utilities)" for managing the information in the schema (Franklin, 
column 2, lines 16-28). Franklin's NAL references the database schema to determine whether 
the software product should be made available to a user seeking access in accordance with 
license terms. 

Franklin's database schema is broadly described, and can be implemented in various 
ways, including as a function of a plurality of API's. Franklin teaches use of "application 
objects" 100, which are "associated" with software applications (see Franklin, column 2, lines 
29-41, see also column 4, line 66 - column 5, line 10). Importantly, Franklin's application 
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objects 100 are "in the network directory services (DS or NDS) database" (column 2, lines 33- 
36, emphasis added). The application objects 100 are not the software applications (i.e., 
applicants' claimed "software products"),/^/* se, but instead represent applications in predefined 
ways in the database schema. 

Franklin also teaches the use of "licensing objects," including for example, licensing 
object 290, 700, 850, which are defined as one of "specialized functional objects" for a "specific 
special purpose" (see Franklin, column 9, lines 44-49). Franklin discloses that "a licensing 
object . . . may be provided in the directory services data base" (Franklin, column 16, lines 44- 
45). In lieu of "application objects," Franklin's licensing objects include "licensing attributes 
852 effective for providing licensing of one or more resource [(e.g., application)] objects 100" 
(column 16, lines 46-48). 

The Examiner states at page 4 that Franklin "discloses a procedure that retrieves licensing 
information from the respective resources" and cites to Fig. 12 and column 14, line 12 to column 
15, line 64. Applicants have carefully reviewed this cited figure and passage and respectfully 
submit that nowhere does Franklin teach "[retrieving] licensing information from the respective 
resources" as the Examiner has stated. Instead, the cited figure and passage relate to modifying 
the database schema and implementing licensing rules as a function of the application and/or 
licensing objects. 

Thus, licensing attributes are not obtained from a resource in Franklin, but rather from 
one or more objects that represent a resource in connection with Franklin's NAL. 

2. Franklin System Requires Controlling Execution Of A Resource In Accordance With 
Licensing Terms 

Applicants' claim 34 defines a system for "correlating metrics associated with a plurality 
of software products" and "wherein the system is not operable to affect operation of any software 
product identified by data correlated by the third computerized software facility." 

The Examiner states that Franklin's "product" can be used "rather than for the direct 
execution of a software product." To support this claim, the Examiner states that Franklin's 
product is used "for database maintenance" in which "operation of the licensed software is not 
essential for this functionality^]" Applicants respectfully disagree. 
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Every embodiment disclosed in Franklin describes control of executing a resource. As 
stated Franklin's "Field of the Invention" section, Franklin provides "run control of applications, 
using directory services systems, as well as simplified, embedded control of application licensing 
with minimum effort." The invention disclosed in Franklin regards a licensing controller, 
notwithstanding ancillary functionality that is provided therewith. 

The Examiner supports his position that Franklin does not require "direct execution of a 
software product," by citing to Figs. 11 and 12, and column 16, lines 12-23. 

Fig. 1 1 represents a consumer object, which includes an "associations list 784" and 
identifying whether a user associated with the consumer object is licensed to access a resource. 
Fig. 12 describes steps associated with modifying a schema in accordance with providing a user 
with access to a licensed resource. Importantly, the cited passage (column 16, lines 12-23) refers 
to "report step 824" which is embodied in a "launch and use step 820" and may be "exectued by 
the licensing API 219 and reported back to the licensing utility 248" (column 16, lines 8-12). 
Report step 824 requires a successful passage through testing step 816 (Fig. 12) that confirms 
that a user is authorized (i.e., licensed) to access a resource. Alternatively, a fail step 826 follows 
the testing step 816 in case a user does not have such authorization. Either way (steps 824 or 
826), any database maintenance steps require the operation of a resource by the user (or lack 
thereof) that is positively affected by Franklin's product. The affecting of operations of a 
resource by a user is always a requirement in Franklin with regard to any resource non- 
operational (e.g., reporting) steps. 

Therefore, the Examiner is incorrect in his assertion that Franklin does not require "direct 
execution of a software product." 

3. Franklin Does Not Disclose "Respective Software Product API Of At Least One Of 
The Plurality Of Software Products" 

The Examiner is silent with respect to applicants' claimed limitation that a single 
"respective software product API of at least one of the plurality of software products" provides 
both agreement data and software product data to two respective software facilities. Franklin, in 
contrast, teaches various application or resource objects that "represent" an application, but that 
are not of a software product, as defined in applicants' claim 34. 
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The Examiner states, at page 4, lines 3-7 of the Examiner's Answer, "Franklin further 
discloses that licensing objects may be implemented as API's" (see column 2, lines 62-67, 
column 7, lines 40 to column 8, line 8; and column 9, lines 4-20). Franklin's licensing object is 
not implemented, however, in a single "respective software product API of at least one of the 
plurality of software products" and that provides both agreement data and software product data 
to two respective software facilities. Instead, Franklin's licensing objects are distinctly 
implemented for licensing and may be "dedicated to the special function of licensing other 
resource [(or application)] objects 100" (Franklin, column 14, lines 66-67). Alternatively, 
application objects may "contain" licensing attributes that are "consumed" by executables (e.g., 
specially programmed dynamically linked libraries (DLL) 194 (Franklin, column 2, lines 52-56, 
see also column 7, lines 25-39). Unlike applicants' claim 34, however, no "respective software 
product API" provides both agreement data and software product data to two respective software 
facilities. 

Further, Franklin's NAL relies upon a plurality of API's that are used with an application 

object. For example, Franklin states, 

Similarly, licensing attributes 160 may identify authorizations, charges, and 
other administrative information required for licensing an application 
associated with an application object 100. As understood in directory 
services systems, an object 92 (e.g. application object 100) represents 
logically certain files of data or executables (e.g. an application), and each is 
often spoken of as the other, though they are not actually the same thing. In 
general, the attributes 150-160 are new specialized attributes associated with 
certain features corresponding to the inventions disclosed herein, and may 
be incorporated into the basic functional attributes 162 associated with 
application objects 100 in general. (Franklin, column 6, lines 21-40). 

Thus, Franklin's licensing controller does not teach or suggest a "respective software product 
API of at least one of the plurality of software products" provides both agreement data and 
software product data to two respective software facilities. 

CONCLUSION ; 

Franklin does not disclose retrieving licensing information from a resource. Further, 
Franklin's system requires controlling execution of a resource in accordance with licensing 
terms. Moreover, nothing in Franklin teaches or suggests a single "respective software product 
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API of at least one of the plurality of software products" that provides both agreement data and 
software product data to two respective software facilities. 

For the reasons set forth above, and in addition to the reasons set forth in applicants' 
reply brief and remarks set forth in applicants' Office Action responses, it is respectfully 
submitted that all rejections to the claims in this application have been addressed to clearly 
define over the prior art. Therefore, the Examiner is respectfully requested to reconsider the 
application and allow the case to issue. 

In the event the actual fee is greater than the payment submitted or is inadvertently not 
enclosed or if any additional fee during the prosecution of this application is not paid, the Patent 
Office is authorized to charge the underpayment to Deposit Account No. 15-0700. 



Respectfully submitted, 
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